2024 AppSec and DevSecOps Keynotes

На рубеже второй половины года мы решили подготовить подборку записей с известных конференций по безопасности, которых стало уже достаточно много. Каждая ссылка ведет на видеозаписи докладов 2024 года. В этом году на всех конференциях наблюдается значительный уклон в сторону безопасности AI и его применения в сфере безопасности на фоне стремительного развития этого направления.

RSA Conference 2024 - одна из крупнейших в мире конференций по ИБ, проводится ежегодно в Сан-Франциско. 300 докладов, включая, конечно же, AppSec и DevSecOps. Чтобы облегчить поиск наиболее релевантных докладов, в чате будут опубликованы ссылки на самые интересные выступления.

BSidesSF 2024. Вторая по известности конференция по безопасности. Совсем немного докладов про AppSec, но кое-что также в разрезе применения AI присутствует.

fwd:cloudsec 2024. Набирающая популярность конференция по безопасности облаков для тех, кому это актуально.

Cloud Native Security Con 2024. Конференция от CNCF охватывает в этом году не только темы безопасности контейнеров и контейнерных сред, но и также безопасность AI/ML, CVE, SBOMы.

phd2 2024. Та самая конференция в России, которая не нуждается в представлении. Кроме отдельного трека по безопасности разработки, есть треки, где так или иначе затрагивается тема AppSec, например, в контексте экономической эффективности.

Также очень ждем доклады от организаторов БеКон 2024 - конференции по безопасности контейнеров и контейнерных сред. Записей пока нет, но есть слайды.

Если вы знаете какие-то конференции релевантные к каналу с доступными записями, присылайте в чат!

#talks

Cloud Threat Landscape

У Wiz, известного вендора занимающегося решениями для безопасности облака, есть вполне достойный внимания ресурс для из изучения - Cloud Threat Landscape.

Что здесь можно найти?

Обновляемый перечень инцидентов с указанием задействуемых инструментов, технологий, группировок, способов получения доступа. Есть отдельная категория для атак на supply chain.

Группировки с ссылкой на инциденты и оперируемые техники.

Техники с ссылкой на ATT&CK тактики. Техники протегированы с разбивкой на облачные атаки, атаки на kubernetes, CI/CD и тд.

Инструменты, используемые при различных ранее известных атаках, упоминаемых в инцидентах, включая названия криптомайнеров, ransomware и тулкитов.

Технологии, на которые нацелены атаки (Docker, Confluence, Redis, Kuberentes и тд), включая способы обнаружения в них уязвимостей (Nuclei, Metaspolit, база CISA KEV)

Данный ресурс мало чем отличается от многочисленных awesome-подборок на github, которые никогда не успевают обновляться в след за появлением огромного количества новых статей, инструментов и техник. В некотором смысла данный ресурс даже хуже, так как полностью поддерживается вендором Wiz без участия сообщества 😅 Тем не менее, обойти данный ресурс мы не могли, ибо он может быть полезен при моделировании угроз для облаков. Кроме того, есть RSS-feed с публикацией атак и инцидентов.

А чем вы пользуйтесь при моделировании угроз?

#cloud

RedFlag

Сегодня на очереди очередной open-source инструмент на стыке AI и AppSec. Цель проекта RedFlag - отдать на AI анализ всех pull requests, чтобы отделить те, которые могут быть проигнорированы, и те, которым команде безопасности нужно уделить особое внимание при ревью. Вот, например, есть набор комитов в проект zed из 29 pull requests (PR), из которых RedFlag отметил 12 в своем отчете. Для одного из коммитов, который добавляет новую команду diagnostics, инструмент предоставил сводку, список измененных файлов, подсветил риск, связанный с модификацией логики обработки путей файлов, и порекомендовал протестировать новую команду на инъекции и directory traversal в рамках тест-кейса.

К инструменту также есть сопутствующая статья. Для того, чтобы инструмент оживить, необходимо подключить языковую модель Claude v3 Sonnet через Amazon Bedrock, а также обеспечить доступ к Jira, чтобы инструмент мог обрабатывать соответствующие тикеты. Далее в статье идет история успеха, где авторы анализировали релиз проекта своей организации, состоящего из 400 PR, из которых было отобрано около 100 PR. Стоимость такого анализа составила всего 8 долларов. В ходе девяти подобных релизов было обнаружено 6 высоких и 8 средних уязвимостей с точностью инструмента около 92%.

Интересен не столько сам инструмент, сколько его идея, простота реализации (это небольшой Python-проект, поддерживаемый двумя мейнтейнерами) и ощутимые результаты.

#ai

#Gartner #Architecture

Binary secret scanning helped us prevent (what might have been) the worst supply chain attack you can imagine

Если история с CrowdStrike – это реализовавшаяся катастрофа в цепочке поставок, то команде JFrog удалось предотвратить атаку, которая потенциально могла бы быть еще более ужасающей. В своей статье команда JFrog Security Research рассказывает, как в одном из публичных репозиториев Docker Hub был обнаружен легаси GitHub токен с админ-правами от репозиториев таких проектов, как python, pypa, psf и pypi. Обладатель данного токена теоретически мог бы скрыть вредоносный код в CPython, который является репозиторием некоторых основных библиотек, составляющих ядро языка программирования Python и скомпилированных из кода на C. Из-за популярности Python, вставка вредоносного кода, который в конечном итоге попадет в дистрибутивы Python, могла бы означать распространение бэкдора на десятки миллионов машин по всему миру.

Токен был найден в бинарном файле .pyc. Как это произошло?

1) Автор добавил авторизационный токен в исходный код.

2) Запустил исходный код (Python-скрипт), который был скомпилирован в бинарный файл .pyc с авторизационным токеном.

3) Удалил авторизационный токен из исходного кода, но не очистил .pyc.

4) Загрузил как очищенный исходный код, так и неочищенный бинарный файл .pyc в Docker-образ.

Какие выводы делают авторы статьи?

- В бинарных файлах тоже могут быть секреты, которые надо искать (отсылка на решение от JFrog).
- Убедитесь, что вы не используете старые GitHub токены (которые были заменены на новые, более безопасные, в 2021 году).
- Предоставляйте доступ к токенам с наименьшими правами.

Отчет об инциденте от самих PyPi можно найти здесь.

#secrets #supplychain

Phantom Secrets: Undetected Secrets Expose Major Corporations

Недавно мы затронули тему появления секретов в неожиданных местах, таких как бинарные файлы. Сегодня мы обсудим обнаружение секретов в удаленных ветках публичных репозиториев. В статье от Aqua исследователи рассказали, как они обнаружили около 18% пропущенных секретов в 50 000 публичных репозиториях, используя команду git clone --mirror вместо стандартного git clone. Авторы подробно объясняют разницу между выполнением этих двух команд и углубляются в нюансы кэширования на платформах управления исходным кодом (SCM).

Почему же ветки на самом деле не удаляются и извлекаются через git clone —mirror?

Если коротко, то удаленные ветки в Git не удаляются полностью, так как они могут быть полезны для восстановления данных или истории изменений. Это связано с тем, что Git, по своему замыслу, должен сохранять максимальную доступность и возможность восстановления данных даже после их удаления на локальном уровне. Когда вы удаляете локальную ветку, удаленные ветки могут оставаться в виде "висячих" ссылок на удаленном репозитории. Эти ссылки могут быть извлечены при использовании команды git clone --mirror, так как она клонирует все ссылки, включая те, которые были удалены локально. У этого явления даже есть оспариваемая CVE-2022-24975 (GitBleed).

Вывод достаточно простой: секрет, который однажды попал в репозиторий, можно считать автоматически скомпрометированным. Для многих использование данного подхода не будет чем-то новым. Соответственно, используйте функции защиты от случайных коммитов (push protection) от ваших SCM и pre-commit хуки, чтобы избегать появления секретов в репозиториях. Если это всё же произошло, то, согласно статье, техподдержка может помочь. Кстати, вслед за статьей Gitleaks и TruffleHog добавили поддержку сканирования через --mirror. Также советуем почитать рекомендации от GitHub - "Best practices for preventing data leaks in your organization".

А как эту проблему решаете Вы?

#secrets

Security Guardrails

Существует термин, введённый Джейсоном Чаном, бывшим директором по информационной безопасности Netflix, который называется "безопасная асфальтированная дорога" (secure paved roads). Этот термин используется в контексте интеграции безопасности таким образом, чтобы она оставалась невидимой. Предположим, разработчики пишут код или администраторы деплоят ресурсы в облако, не осознавая, что делают это безопасно, не придерживаясь при этом множества руководящих принципов.

Звучит как сказка, но в настоящее время это всё чаще обсуждается в контексте реализации так называемых Security Guardrails. Это достаточно общий термин, в рамках которого разработчикам и администраторам по умолчанию предоставляются заведомо безопасные функции, классы, ресурсы и механизмы для повседневной работы. Например, вот авторы статьи предоставили разработчикам кастомные классы Terraform CDK для создания ресурсов RDS. Вместо того чтобы создавать RDS с множеством мисконфигураций, как это обычно происходит, разработчики могут воспользоваться классом DatabaseInstance, в котором уже встроены шифрование, ограничение публичного доступа и другие меры безопасности. Затем они передают класс на исполнение функции generate_databases, и безопасники ликуют.

Развивая данную концепцию, мы приходим к ситуации, когда внутренним пользователям предоставляются исключительно безопасные по умолчанию утилиты, сервисы, механизмы SSO, аутентификации и авторизации, где пользователь заведомо не может сделать что-то неправильно. Это противоречит подходу большинства вендоров, которые стремятся сделать запуск сервисов максимально простым, не зная всех особенностей каждого заказчика. Соответственно, это приводит к поддержке команды безопасности, которая создает Security Guardrails под нужды организации, делая их, при этом, простыми в эксплуатации. Такие команды безопасности обрели название Security Platform Engineers, статьей про которых мы тоже решили поделиться в продолжении повестки. В России развитие таких команд особенно заметно на фоне стремительно появляющихся AppSec платформ, разрабатываемых in-house (привет Альфа-Банк, VK, Yandex и другие).

Это действительно интересная ниша, где видится появление большого количества стартапов. Например, Semgrep даже сделали бесплатный курс про Secure Guardrails, где они объясняют своё видение их применения в контексте своего инструмента.

Немного аналитики от Gartner: с правого края "повзрослевший" DevSecOps; слева "молодые" Policy as Code, AI ассистенты и прочее... Любуемся, прогнозируем, готовимся к выходным.

#Gartner #Hypecycle

Devici Threat Modeling Tool

Если вы хотя бы немного следите за интернациональным аппсек-комьюнити, то вы наверняка сталкивались с материалами Криса Ромео (Chris Romeo). У Криса за плечами огромное количество докладов на конференциях, включая RSA Conference и OWASP Global AppSec, подкастов, блогов и исследований, значительная часть которых посвящена моделированию угроз.

Недавно Крис основал собственный стартап Devici для автоматизации моделирования угроз. Поскольку Devici поддерживает 3 модели угроз бесплатно и практически без ограничений для команд до 10 человек, а у Криса безупречная репутация, мы с командой не могли пройти мимо и решили попробовать этот сервис.

Идея следующая:

- Создается модель угроз в виде сущности, которая может иметь различные статусы, частоту обновлений, критичность и даже время, потраченное на моделирование.
- Команда совместно составляет архитектуру приложения, где для каждого компонента назначается атрибут в свободной форме, например, Database, API, WAF, User, Admin, MySQL, RDS, CloudTrail и т.д. В этом помогает небольшой AI, который подбирает нужные атрибуты по запросу пользователя.
- На основе выбранных атрибутов инструмент назначает список угроз. Связь осуществляется через преднастроенную библиотеку угроз, привязанных к атрибутам. Также к каждой угрозе прилагается рекомендация по устранению.
- Далее команда анализирует все назначенные угрозы по всем компонентам, в результате чего формируется to-do лист, назначаемый конкретным ответственным.

За исключением местами непродуманного UX и не всегда мгновенных откликов, инструмент выглядит интересным и перспективным. Индивидуальные исследователи могут использовать инструмент для поиска идей для своих моделей угроз, а команды, работающие за рубежом, могут рассмотреть Devici в качестве дополнения к своим процессам. Авторы также экспериментируют с инновациями и представили новый класс инструментов Design-SAST, который позволяет формировать модель угроз на основе анализированного кода. В будущем возможна генерация списка угроз с помощью AI на базе назначенных атрибутов.

#threatmodeling

AppSec != DevSecOps

Нашу команду часто подключают к процессам выстраивания безопасной разработки в компаниях. В свете продолжающихся изменений регуляторики будут ещё чаще. Помимо вопросов относящихся к специфике HR, существует пул hard skills задач, которые начинаются с четкого определения зоны ответственности человека и требуемых компетенций. Сегодняшний пост посвящен рефлексии и размышлениям о разнице между AppSec, DevSecOps и ProdSec на фоне неоднозначного видения этих ролей в компаниях, что часто приводит к недопониманию на интервью и затрудняет подбор подходящего сотрудника.

Все, что вы прочитаете далее, является субъективным рассуждением на основе эмпирики.

AppSec

Цель: Обеспечение безопасности приложения. Это отражено в KPI, включая количество найденных уязвимостей, охват тестируемых приложений и глубину анализа. В задачи входят анализ архитектуры, моделирование угроз, ревью кода и тестирование безопасности. Роль AppSec существует достаточно давно, с начала 2000-х годов, когда появилась организация OWASP. Хотя о результативности этой роли можно порассуждать, подробнее писали в относительно старом посте.

DevSecOps

Цель: Автоматизация процессов безопасности и интеграция безопасности в DevOps. В KPI входит адаптация инструментов безопасности в SDLC и автоматизация проверок безопасности на уровне CI/CD. Сюда часто включается безопасность платформ Kubernetes и облачных сервисов. Концепция DevSecOps начала формироваться в 2012-2014 годах.

Несмотря на явные различия в целях и задачах, часто можно встретить распределение ролей в командах, где AppSec-инженер в крупной компании, способной разделить ответственность, занимается встраиванием инструментов в CI/CD. При этом у инженера явный уклон именно в безопасность веба и мобильных приложений. В итоге мы видим, что внедрение произошло, но нередко оно выполнено неэффективно, не учитывая многие аспекты, к которым приходят опытные DevOps-инженеры. На рынке AppSec также существует множество кандидатов, приходящих на интервью с единственным опытом встраивания сканеров, многие из которых никогда не работали с инструментами вроде Burp Suite.

Product Security

Кто такие Product Security, о которых мы слышим все чаще последние 2-3 года, особенно на интернациональной рынке? Это команды, занимающиеся безопасностью продукта в целом, включая управление уязвимостями продукта и его инфраструктуры, а также облачную безопасность. Некоторые компании даже имеют команды Product Security как единственных специалистов по безопасности. ProdSec также тесно взаимодействует с Product Management, что нечасто встречается в AppSec. ProdSec интегрирует безопасность в жизненный цикл пользователя, внедряя MFA, историю входов, CAPTCHA и другие механизмы, тесно сотрудничая не только с dev и product, но и с маркетингом и другими бизнес-направлениями. Команде ProdSec, как и AppSec, не обязательно иметь в составе DevSecOps-инженера, который может существовать отдельно в команде DevOps.

Это зарождающееся разделение, где ProdSec получает больше доменов ИБ под управление, обусловлено, на мой взгляд, как и тесным переплетением слоев абстракций (cloud-native инфраструктура) так и непониманием старой школы инфраструктурных безопасников особенностей разработки и того, что нужно делать, чтобы быть гармоничным участником процесса. Любое изменение конфигурации в облаке, применение патча или правила на WAF может сильно повлиять на работу пользователя. Поэтому любое изменение для продуктов, независимо от инфраструктурного или прикладного слоя, может проходить аналогичный цикл SDLC, как и любое изменение кода.

P.S. И в этом процессе возникновения новых ролей можно разглядеть интересный элемент, дополняющий наш любимый shift left. Этакий shift right: когда приложения и процессы становятся все более сложными и запутанными, а мы чтобы приоритезировать необъятное фокусируемся прежде всего на опыте клиента, на том, что находится максимально справа. А затем "раскручиваем" то необходимое, что нужно для того чтобы его опыт состоялся (включая требования к ИБ и соответствие регуляторике).

#имхо

Container and Kubernetes Security Fundamentals

Я уверен, что многие из вас заметили, что мы редко затрагиваем вопросы безопасности Kubernetes и контейнеров, хотя обладаем соответствующей экспертизой. Поэтому вечерком, под чашечку расслабляющего чая, давайте преисполнимся оркестрации.... Мы не могли пройти мимо и решили опубликовать уже не новую, но постоянно обновляемую серию видео и статей от известного исследователя Rory McCune под названием "Kubernetes Security and Container Security Fundamentals" (ссылка на статьи). Материалы охватывают важные аспекты безопасности Kubernetes, включая его компоненты, а также такие механизмы безопасности контейнеров, как capabilities, namespaces, AppArmor, SELinux, cgroups и seccomp-фильтры.

В одном из последних материалов, опубликованных около двух недель назад, рассматривается вопрос авторизации в Kubernetes, включая модули авторизации (AlwaysAllow, AlwaysDeny, Node Authorizer, ABAC, RBAC) и авторизацию на уровне компонентов.

Rory McCune известен своими статьями еще с тех времен, когда работал в Aqua Security. Большую известность он получил как соавтор Kubernetes Benchmark и Docker Benchmark от CIS, а также как автор документа "Guidance for Containers and Container Orchestration Tools" для PCI DSS.

Этот курс идеально подходит для начинающих, а учиться никогда не поздно! Даже ночью 🙃

#k8s #docker #containersecurity

А между тем череда интересных митапов продолжается. Вот и Купер.тех (ex-СберМаркет) подготовил свой DevSecOps митап со спикерами из RuStore, Positive Technologies, Купер.тех (ex СберМаркет), SolidLab и MTS Web Services.

Дата: 21 августа в 19:00

Место: Москва, офис Купера + онлайн

На митапе будут представлены доклады на следующие темы*:

- Как выстроить DAST на Open-Source: гибкое использование Nuclei и ZAP под сервисы компании
- Вредные советов для вашего ASPM.
- Написали свою DSO-платформу, но все равно купили ASOC. Да как так-то?…
- Опыт тестирования Defect Dojo SASTами
- Какой должен быть SAST?

*по итогам каждого доклада и в афтерпати - обсуждение тем со спикерами

Зарегистрироваться на митап можно тут: это чтобы попасть в офлайн или чтобы не пропустить ссылку на трансляцию, если интересно присоединиться в онлайне.

#event #инфо

Harnessing LLMs for Automating BOLA Detection

Одна из самых распространённых уязвимостей в веб-приложениях — это broken access control. На сегодняшний день SAST и DAST бесполезны при их поиске, и всем известно, что выявление таких уязвимостей решается исключительно ручным тестированием с помощью плагинов для Burp, таких как Autorize, AuthMatrix, Authz.

Однако, недавно мы наткнулись на статью от Unit42 (Palo Alto Networks) о том, как они автоматизировали поиск уязвимостей типа broken object level authorization (BOLA) с помощью ИИ. В качестве входных данных используется спецификация OpenAPI, после чего механизм ищет потенциально уязвимые API, где происходит обращение к объектам (например, username, email, teamId, invoiceId, visitId). Далее строится дерево зависимостей между этими эндпоинтами и формируются тестовые кейсы, в которых инструмент пробует различные сценарии обращения к объектам на основе имеющихся доступов двух пользователей. Если один из пользователей имеет доступ к объектам другого, то существует высокая вероятность наличия уязвимости BOLA.

Звучит достаточно интересно и логично автоматизировать такого рода тестирования! В результате исследователи обнаружили уязвимости в Grafana (CVE-2024-1313), Harbor (CVE-2024-22278) и Easy!Appointments (целых 15 CVE). Они также отметили, что эксперименты показывают: обратная связь от людей постоянно улучшает точность и надёжность ИИ.

В конце статьи также много полезных ссылок на смежные исследования Unit42.

P.S. Кстати, вот еще один прекрасный пример поиска CVE с помощью LLM - анализ вылетов на предмет полезности при фаззинге браузера.

#ai

Security Templates

Сегодня без сложных постов, уязвимостей и исследований. Вместо этого мы хотим поделиться парой полезных шаблонов!

Первый из них — шаблон моделирования угроз по STRIDE для Miro от самого Head of Product Security Miro. Этот шаблон наглядно демонстрирует процесс моделирования угроз и включает сопутствующие диаграммы, которые помогают на каждом этапе составления списка угроз.

Второй — это целый набор шаблонов от Robert Auger. Роберт делится материалами, которые помогали ему на его пути в построении программ bug bounty, управления уязвимостями, внешнего пентеста и реагирования на инциденты. Во всех своих шаблонах Роберт опирается на свой опыт в таких компаниях, как PayPal, eBay, Box, Workday и Coinbase. В качестве примера к посту приложена упрощенная диаграмма процесса bug bounty. Еще нам в целом понравился чеклист в подготовки построения процесса vulnerability management, который также учитывает AppSec-процессы. По нему хорошо можно проследить попытку автора передать именно свой личный опыт.

#templates #process

Making Sense of the Application Security Product Market

Недавно мы опубликовали пост о наших размышлениях на тему AppSec, ProdSec и DevSecOps, который вызвал широкий отклик среди наших читателей в чате. Сегодня мы наткнулись на статью, которая повторяет многие из этих тезисов, дополняя их новыми аспектами, о которых мы хотели бы также поговорить.

- AppSec охватывает буквально все: приложения, CloudSec, ProdSec, DevSecOps, AI Security, SaaS Security, Data Security, Runtime Security. Это также перекликается с определением CNAPP от Gartner.

- Систематичные практики AppSec по устранению выявленных проблем пошли дальше и распространись на облака, API, что привело к появлению Product Security, который включает AAA, privilege management, secrets management, encryption и тд.

- SAST, DAST и WAF по отдельности остаются классами инструментов, которые генерируют больше шума, чем пользы. По мнению автора, они продолжат существовать, но скорее станут частью более широкого кастомизированного класса продуктов.

- CSPM-решения вроде Wiz добились успеха благодаря отличному UI/UX и механизмам приоритизации, таким как "Attack Paths".

- ASPM-решения являются преемниками успеха CSPM, но с множеством "но", включая сложность, необходимость зрелых процессов AppSec, а также зависимость от качества подключаемых решений.

- На сегодняшний день AI оказывает наиболее ощутимое влияние на триаж и предоставление рекомендаций по исправлению, но не более. Участие человека по-прежнему остается ключевым и незаменимым.

Канал существует с 2019 года, и за это время было весьма любопытно наблюдать за тем, как меняется индустрия. То, что почти пять лет назад считалось полезным советом для CISO, сегодня утрачивает свою актуальность на фоне появления более прикладных решений.

#trends

GitHub Actions Exploitation

Мы редко пишем про векторы атак и уязвимости, связанные с GitHub Actions, так как в России платформа по понятным причинам не используется. С другой стороны у нас есть читатели и не из России, а за каждой конкретной атакой скрываются полезные концептуальные идеи и универсальные принципы. Поэтому когда мы нашли блог SynAcktiv, где они делятся увлекательными атаками на GitHub Actions, мы были просто обязаны этим поделиться.

Итак, рассмотрим одну из интересных атак. Атака на цепочку поставок CI через инструменты безопасности, а именно через Dependabot, сканер уязвимых зависимостей!

1) Атакующий создаёт форк репозитория, куда собирается заинжектить вредонос.

2) Затем он тригерит работу Dependabot, который делает pull request (PR) в созданный форк, предлагая обновить библиотеку до безопасной версии. При этом создаётся новый форк от Dependabot для слияния. На этом этапе авторы нашли способ изменить то, что именно добавляется в PR от Dependabot, и внедрить вредоносный код (посредством излечение секрета бота через self-hosted runners и коммуникации с Dependabot API). Хотя это уже звучит угрожающе, при внимательном ревью PR вредоносные файлы все равно могут быть обнаружены, поэтому давайте продолжим цепочку эксплуатации.

3) Далее атакующий берёт новый PR, созданный Dependabot, и вместо слияния со своим форком отправляет его в основной бранч репозитория жертвы (main). GitHub позволяет изменить цель PR, перенаправив его из одного бранча в другой. В этом случае, хотя PR и был создан ботом, авторство будет приписано атакующему, так как он инициировал действия, а не сам Dependabot.

В обычной ситуации на этом всё должно было бы закончиться, но не в случае с авторами репозитория spring-security. Они намудрили с actions на GitHub, разрешив автоматическое слияние PR, если github.actor == 'dependabot[bot]'. Проблема в том, что в контексте GitHub github.actor — это не автор бранча, а последний пользователь, совершивший действие с PR!

4) Атакующий вызывает Dependabot повторно в своём PR в main, после чего уязвимый workflow автоматически сливает PR, включая вредоносный код.

Фикс в данном случае - использовать github.event.pull_request.user.login, а не github.actor, который выдает именно автора PR как и ожидается.

SynAcktiv также поддерживает собственный инструмент octoscan для анализа безопасности GitHub Actions, куда они уже добавили файндинги со своих ресерчей.

Среди других статей от них мы также рекомендуем ознакомиться с Introduction, где авторы разбирают базовые аспекты атакующего на GitHub Actions, а также со статьей про Untrusted Input.

Здесь важно понимать, что данная проблема не является уникальной для GitHub; аналогичные проблемы и векторы атак могут возникнуть в любом элементе цепочки поставок. Обратите внимание на причины, которые привели к появлению уязвимости:
- Наличие вызовов в платформе GitHub, название которых говорит совсем не о том, как их воспринимает конечный пользователь с позиции "здравого смысла".
- Использование вызовов авторами, не до конца разобравшимися в их логике работы.
- Автоматический обход ревью, основанный на неочевидных скриптах, которые могут быть использованы широким кругом лиц...

А если вы еще пока далеки от темы CI/CD Security, но хотите с легкостью понимать, о чем здесь идет речь, вот вам awesome ci-cd attacks, где есть и Threat Matrix, use cases, инструменты и многие другие ресерчи.

#cicd

Друзья, подписчики и читатели! В день знаний символично открыть новую страницу в истории канала. На эту идею нас натолкнули последние посты, и размышления об эволюции безопасной разработки и развитии prodsec. Что мы имеем?

- DevSecOps "как вещь-в-себе" вылетает из хайповых трендов (привет аналитика gartner!);
- DevSecOps без наличия зрелых сопутствующих практик, вроде развивающегося AI, reachability analysis и ASPM теряет смысл (а на самом деле, если вспомнить лучшие практики и системный подход к управлению ИБ а-ля ISO 27001 - никогда его не имел, как не имеют смысл отдельные меры не встроенные в систему управления "как в целое");
- Написание интересных постов про DevSecOps без затрагивания других областей, типа AppSec и ProdSec, стало практически невозможным - это либо пережевывание "хорошо известного старого" (для чего появляется все больше курсов, гайдов, программ); либо достаточно частная и слишком узкая тема (не интересная широкой аудитории);
- На фоне этого нам удается находить все меньше статей и материалов про голые практики DevSecOps. Все меньше людей довольствуются фразой "DevSecOps - это стратегическое решение". Комьюнити уже не впечатляют выстраивание secure SDLC как таковое, комьюнити интересно видеть то, что поможет им получить как можно больше ощутимого профита, а это зачастую выходит далеко за пределы автоматизации в CI/CD и затрагивает проблемы далеко за рамками DevSecOps.

Таким образом за 5 лет существования канала тематика DevSecOps в пространстве .ru прошла пик, и вышла на определенный "уровень зрелости". А мы, чтобы не потерять интерес к ИБ и сохранить полезность канала для коммьюнити постараемся расширить круг тем, и оставаться на фронтире кибербезопасности, чего бы нам это не стоило 🙃 А что думаете вы? О чем бы вам хотелось читать на Security Wine и поддерживаете ли вы расширение тематик?

P.S. Дополнительно обращаем внимание, что заявление выше не означает отказ от "классики жанра": в канале продолжат выходить и более консервативные материалы, ровно как сохранится история "прошлых постов". Поэтому вы всегда сможете вернуться "в прошлое" и найти актуальные для ваших кейсов материалы.

#оргвопрос #strategy